代码评审工作流

代码评审（Code review）对于提高团队的整体水平，减少 BUG，提高代码质量等方面都很有帮助，唯一可能需要担心的就是可能会对短期进度和效率有一定影响，为了最大化获得代码评审的好处，并降低对效率的影响，现制定以下评审工作流，以后暂时用这个流程执行，并在执行过程中根据体验和反馈不断优化和改进。

基本思路

1. 我们只用 Gitlab 工具 Review 线上 master 分支的 Merge Request(MR)，迭代内部的代码问题，通过迭代内的团队沟通来解决。

2. 提交 MR 时，必须要填写描述，描述要包含本次 MR 做的事情，要点，评审人通过 Assignee 的方式指定，我们提交 MR 时指定和你本次提交的代码逻辑相关的工程师，或者对代码比较熟悉的工程师，或者比较资深的工程师进行 Review，其他人也鼓励共同参与 Review，但鉴于 Hotfix 的特殊性，还是以主要评审人（Reviewer）的快速响应为主。

3. Review 的时候的重点放在 BUG 和拼写错误，命名等代码风格的问题比较次要，可以提，但 MR 的发起者不是必须接受

4. MR 主要评审人必须做出反馈，如果认为没有问题，就表达没有问题即可，如果有问题要利用 Gitlab 的基于代码行的评论的方式进行指出，如果没有问题，评审人评论后将 Assignee 设置成我，如果有问题，评论后 Assignee 设置成发起人，发起人处理完以后，Assignee 设置成我。

5. MR 发起人对所有评审人的反馈需要做出响应，不管是否接受，接受的修改后点击解决，不接受的，评论后点击解决。

6. 发起 MR 的时候，除了 Assign 评审人之外，还要口头通知一下。

只有看到所有提出的问题都修复，Master 才会接受提交的 MR。